r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

Not sure if someone can just kill the CI? It has been going for 1h 30mins and it usually consistency for others takes 40mins. I think my misunderstanding of traits/impl has caused an infinite loop maybe of nth() calling itself?

I think my misunderstanding of traits/impl has caused an infinite loop maybe of nth() calling itself?

Maybe let's figure out if this cleanup is really possible first (having the CI pass).

@kennytm
I removed nth() and __iterator_get_unchecked() from impl<A: Iterator, B: Iterator> Iterator for Zip<A, B> as it is just the same as the default in iterator.rs. Although now impl<A: TrustedRandomAccess + Iterator, B: TrustedRandomAccess + Iterator> Iterator for Zip<A, B> which has the specialised implementations is complaining it can not create the specialised functions as there is no default implementation in impl<A: Iterator, B: Iterator> Iterator for Zip<A, B> even though it should just use the default in iterator.rs.

I have read the documentation and various posts but can not seem to find how to implement my desired behaviour above, would you know how?

As I was looking at writing a specialised nth_back() for TrustedRandomAccess. At the moment I would have to just copy and paste the default implementation across from iterator.rs for impl<A: Iterator, B: Iterator> Iterator for Zip<A, B> and only specialise in impl<A: TrustedRandomAccess + Iterator, B: TrustedRandomAccess + Iterator> Iterator for Zip<A, B>.

Just concerned about the implementations changing in iterator.rs and not being changed in zip.rs like it was for nth() now using advance_by() and not a loop, where as in zip.rs it is still using the older method of a loop.

☔ The latest upstream changes (presumably #79319) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@DeveloperC286 Ping from triage! What's the current status of this?

@DeveloperC286 Ping from triage! What's the current status of this?

Could not figure out how to clean it up as much as I wanted. However I think the PR I have now is an improvement so this is good for review now 👍

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

☔ The latest upstream changes (presumably #81089) made this pull request unmergeable. Please resolve the merge conflicts.

Hi @kennytm any chance you can take a look? I think my PR makes the code more simple/clean. Let me know your thoughts and I can just close the PR if you think it does not 👍

@bors r+ rollup=iffy

📌 Commit 152f500 has been approved by kennytm

@bors r- failed in #81559 (comment) I believe

@DeveloperC286 Ping from triage: Seems this pr is breaking other crates from compilation in the rollup above. Would you mind investigating into this? Thanks!

☔ The latest upstream changes (presumably #83580) made this pull request unmergeable. Please resolve the merge conflicts.

ping from triage:
@DeveloperC286 - can you please resolve the merge conflict and set the tag to S-waiting-on-author ? thank you.

ping from triage:
@DeveloperC286 - fyi a build check is failing, can you post your status on this PR?

ping from triage:
@DeveloperC286 - fyi a build check is failing, can you post your status on this PR?

Sorry struggled for a long time to reproduce the issue by bors in the roll up, but now the issue is present in the regular test suite.

Using the git bisect command the issue is with the commit refactor: removed ZipImpl, just do not understand the issue and trying to resolve it.

The job x86_64-gnu-llvm-10 failed! Check out the build log: (web) (plain)

   Compiling tracing-attributes v0.1.13
   Compiling rustc_macros v0.1.0 (/checkout/compiler/rustc_macros)
   Compiling chalk-derive v0.55.0
   Compiling chalk-ir v0.55.0
error[E0282]: type annotations needed for `(_, _)`
   --> /cargo/registry/src/github.com-1ecc6299db9ec823/serde_derive-1.0.125/src/de.rs:646:52
    |
646 |     let let_values = vars.clone().zip(fields).map(|(var, field)| {
    |                                                    ^^^^^^^^^^^^ consider giving this closure parameter the explicit type `(_, _)`, with the type parameters specified
    |
    = note: type must be known at this point
   Compiling tracing v0.1.25
error: aborting due to previous error

For more information about this error, try `rustc --explain E0282`.

ping from triage:
@DeveloperC286 - can you please address the broken build, thanks.

@DeveloperC286 I'm gonna close this due to inactivity. Feel free to reopen or create a new pr when you got time to work on this, thanks!